[The inventors use the term Internet to mean the Internet operating environment. This refers to any configuration that leverages the collection of the Internet protocol suite, an Internet browser, and the Java platform. As such, the term Internet encompasses the worldwide Internet, corporate Intranets, and cooperating Extranets. The inventors draw specific distinctions between Internet, Intranet, and Extranet only when required for clarity in the context of the discussion.]
The growth of the Internet and its associated operating environment has taken even its most ardent users by surprise. No matter what metric is used--the number of users, the number of participating organizations, the geographical reach, the amount of content, or the number of times one uses the Internet in the course of a day--this growth can only be characterized as explosive.
Simultaneously, the vendor community is rushing to provide point solutions that allow users to harness the communication power of the Internet. Often, these solutions seek to retrofit an existing environment to the Internet, or merely to provide a visually appealing user interface. These approaches lead to piecemeal solutions which do not address the most basic requirements for building robust, efficient, and secure applications for the Internet.
There are four salient requirements for building business-class applications for the Internet and its associated operating environment. The first requirement is support of non-provisioned client applications. Users need an environment where there are no preexisting software requirements for the client system. This means that the only software that the client system needs to have is a browser. This requirement has grown out of the cost and complexity associated with purchasing and installing software on large numbers of client systems. Implicit in this today is support for the Java Virtual Machine (JVM), within which one can run Java applets, which has given rise to the concept of the Network Computer (NC).
The second requirement is to provide for the natural flow of business events. On the Internet, entities can communicate business events (e.g. ordering an item, hiring a new employee, etc.). These event-based application transactions then need to trigger business processes automatically, efficiently, and securely. However, the entities involved in such events should not know about each other, i.e., decoupled communication is needed. Furthermore, the communicating entities should not have to wait for each other, so asynchronous communication is also needed.
The third requirement is guaranteeing robustness of information delivery. While the Internet is an excellent communication medium--having a planet-wide geographical reach, being very economical, and running a standard protocol, etc.--it does not provide for features that is needed to build business-class applications. Therefore there also is a need to raise the intelligence of information (or messages) on the Internet by providing for security, reliability, and transactional semantics, and all of this has to be done in an efficient and scaleable manner.
The fourth requirement is to allow enforcement of security policy in its entirety. A solution that does not address all security requirements, or at least the most important elements of one, will fail. Organizations also need to be able to implement security policies which are flexible, yet which are easily and effectively enforced.
In sum, the Internet is excellent as a communication medium. However, it lacks inherent support for important aspects of business-critical applications. The present invention complements the Internet by providing comprehensive security, thereby addressing one of the most important above requirements.
Elements Of A Security Policy:
[The reader is assumed to have basic familiarity with the publish/subscribe model of message trafficking.]
There are seven important requirements often listed in security policies, each of which may be posed as a question. These are:
Authentication--Who are you? PA1 Authorization--What can you do? PA1 Privacy--Who can see the data? PA1 Integrity--What if data is changed while in transit? PA1 Nonrepudiation--Can the originator of a transaction be proven? PA1 Audit--What important event happened when? PA1 Management--Can the security policy be dynamically managed and enforced? PA1 Secure Single Signon (SSSO)--Can users maintain a single password for access to all resources? PA1 Delegation--Can an entity act on behalf of another?
Also sometimes considered, but of lessor importance, are:
These later items are important issues, and some discussion herein will address particular aspects of them, but the seven requirements listed first above continue to be the most important. [Note that firewalls are not listed. Firewalls are merely a technology that is meant to address some of the listed issues, i.e., firewalls are merely partial solutions to underlying user concerns.]
Existing Solutions:
Much has been said and written about Internet security, and specifically its inherent lack. Within the last three years several new security protocols as well as extensions to existing protocols have been proposed and adopted. Among the most popular of these are the Secure Socket Layer (SSL) protocol, extension to IP for security (IPSEC), and Simple Key management for IP (SKIP). Most such protocols deal with privacy and integrity protection. And some deal with authentication in specific ways. For example, the SSL authentication protocol requires that the parties have a digital certificates. However, none of these deal with access control and nonrepudiation. Therefore, in summary, there is no single protocol that deals with all aspects of security in one comprehensive package. A limited discussion of methods employed by existing protocols follows.
The application may be responsible for enforcement of security: With many existing security solutions the application developer is responsible for enforcing the security policy. This type of security solution merely presents the application developer with a set of Application Programming Interfaces (API's). Implementations of SSL, Kerberos, the Distributed Computing Environment (DCE), any system based on the Generic Security Services API (GSS API), and CryptoAPI (from Microsoft) are examples of security solutions with extensive API's. This method leads to the application developer needing to learn the API, and then being responsible for at least some aspects of security, which in turn makes for complex applications that are difficult to change in the face of dynamic security requirements.
Preexisting software may be required: With both SSL and CryptoAPI the client must be provisioned with a "security service provider" (usually RSA's toolkit) for basic cryptographic functions such as encryption and message digesting.
Address authentication, privacy, and integrity: Most security solutions, including SSL, VPN (Virtual Private Network), IPSEC, and SKIP simply address authentication, privacy protection, and integrity protection. There are no provisions for other important security requirements such as authorization and access control, nonrepudiation, audit, and central administration and management.
Secure Socket Layer (SSL): SSL has provisions for authentication, privacy, and integrity. However, as noted previously, application developers must program to an API. The SSL authentication protocol is based upon digital certificates and associated private keys. Therefore, even though SSL is based upon a public key infrastructure, the private key of a principal is only used for establishment of secret session keys, which are in turn used for privacy and integrity protections. There are no provisions for nonrepudiation.
Simple Key Management for IP (SKIP): SKIP provides for authentication, privacy, and integrity with no programming requirements. However, security is provided at the network/transport levels (e.g., TCP/IP) and not at the application layer. Another way to say this is that SKIP, SSL, and IPSEC provide transport (or channel) security as opposed to message (or application) security. As such, with SKIP and similar protocols (including SSL) either all messages are protected or no message is protected.
Extensions to IP for Security (IPSEC): This is the same as SKIP.
Virtual Private Networks (VPN): This solution is generally offered by firewall vendors. It is in the same category as SKIP and IPSEC. In fact, some vendors use IPSEC and SKIP to implement their VPN.
Java as a language has a number of protection features which are enforced by the runtime environment. These features are designed to prevent a downloaded applet from maliciously or accidentally corrupting the user's computer, or otherwise transfer information from the user's computer to the server that sent the applet. With the Java Developer's Kit (JDK) 1.1 some security features have been built into the language. Some examples include provisions for digital signatures, message digesting, and very simple key management. However, it should particularly be noted that Java is a language which offers "safety features," but which has had no "security" features until the release of JDK version 1.1, and these features are not comprehensive. The present invention may be implemented using the Java language, and thereby some aspects of security may be provided for using features of this language, but it should be appreciated that Java is merely a language (i.e., a tool), and it is not a solution by itself. Further, it places the burden of providing a comprehensive security solution on the application developer.
Approaches To Building Secure Applications:
There are two main approaches to building secure applications. The first of these is an application based approach, where each application is responsible for enforcing some or all aspects of the security policy. Existing software products that take this approach provide an API for the application developer. Most vendors in this category allow an application to be build for authentication, privacy, and integrity. Enforcement of access control (i.e. authorization) is usually the most difficult. One can cite examples of writing so-called Access Control Managers for DCE, and the complexities associated with that. In any case, this approach usually leaves the possibility of incorrect implementation. Moreover, if the security policy changes, the application must then also be changed to reflect the new policy (for example, when a new access control permission is added to the system the application must check to see if the user is authorized to perform an operation according to the newly added permission).
The second approach to building secure applications is an automatic approach, where the application developer is completely relieved from enforcing any aspect of the security policy. The present invention is an example of this approach, wherein a client at runtime and a message broker collaborate to enforce the security policy, employing the premise that minimizing or eliminating application involvement in enforcing a security policy greatly enhances compliance with the security policy.
In a "perfect" implementation of the automatic approach there would be no API's. Unfortunately such is not realistic, since there i, a minimum quanta of information which must necessarily be gathered for security purposes. The problem then becomes what is that minimum, and how can it be obtained efficiently and in the least user burdensome manner? It is the inventors' contention that a user ID and a password are the minimum quanta. Accordingly, in implementations working with the invention presented herein, the application is responsible for soliciting minimal authentication information (e.g., user ID and password), and delivering it to the invention. The inventors' position is that soliciting a user ID and password are really a natural part of an application interaction with the user. This may be done through the use of a Java class, and the inventors do not consider such a class and its associated API to be an onerous security API.
It should be noted, however, that in systems where a password is not the ultimate means of authentication, a password is still used to obtain "credentials" for authentication. One can cite the example of a smartcard where a password or a PIN is used to gain access to a smartcard where the private key of an individual is stored.
It is the inventor's connection that all authentication models can be abstracted to soliciting a password from the user, irrespective of whether the password is ultimately used as a means to authenticate the user.